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Simulating web cookies for non-cookie capable browsers 

(67) Cookie support Is simulated at a web server for clients whose browsers era not cookie enabled/capable, 
thus enabling the clients to use cookie based sites. A plug-In apptk:ation (40 fig 2) Is provide for web server (39, 
fig 3). In one embodiment this plug-in application first determines whether or not a client's browser is cookie, 
capable/enabled by parsing the Incoming http request header, (eg by tooklrig for browsers which are known 
not to support the use of cooicies). Non-cookie capable/enable clients furnish the server wHh user IDs and . 
passwords using bask: web authentication. This identification is used to Identify/create a relevant proxy cookie 
for the client. Once created a proxy cookie is stored on a database (43, fig 2) local to the server (39, fig 2). Tlie 
plug-in then simulates and proxies a cookie for the client (eg by inserting the cookie into the http request 
header). In a further embodiment a proxy cookie is always created for a client and no initial check for cookie 
compatibility Is made. In this case a proxy cookie is used only when the client fails to retransmit a cookie that 
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S1M0IATIH6 WEB COOKIES FOR HOH-COOKIB GMPABLB BROWSERS . . 

BACKGROUND OF THE INVENTIC3N 

• ■ , ■ * »* • 

The present invention relateis to the field o£ con^uter networks and 
more particuXafly to the Internet and World-Wide Web (WWW or simply^ thie 
Web) networ)ts. 

The Internet is a network of computers and coniputer netwrks linked 
worldwide. The Web is a service that provides graphical links motig the * 
computers in the Internet. This is accomplished %#ith the HypexText. Markiqp 
Language (HTML) that provides the functionality for creating user-friendly 
links among Web pages. Users of the Web employ Web browiecrs B^ch as 
Netscape and Hosaic to browse the Web. 

Many Web browsers have the capability to accept certain pieces (one 
or more packets) of information called cookies from Web sites visited. 
Cookies are transmitted by Web servers to the user (client) so that they 
are stored by the Web browser in the user«8 computer and read back by the 
server on subsequent visits by that usef T llie'cb^ automatically 
transmitted by the user's conputer to the server on subsequent visits to 
that site. Servers can collect information about the user including 
product or site preferences or other personal information provided by the 
user, and write that information or an access key to that infonbation into 
the cookie. Thus, the Web server can tailor the content presented to the 
user based on those preferences. All of this can be done transparently to 
the user. Cookies serve the purpose of identifying users and their 
preferences to Web sites over multiple visits to that site. 

While many Web users do not mind receiving cookies, others do not 
like them, viewing them as invasive intruders and hence those users disable 
their browsers' ability to receive or process cookies. Moreover, some Web 
browsers do not support them at all. However, many sites have 
infrastructure that is designed to vrork with cookies and which would not 
operate fully or at all when the site is visited by users with non- cookie 
enabled browsers. Therefore there is a need for a method and system to 
overcome the above shortcomings in the art. In particular, it is highly 
desirable to overcome these shortcomings without requiring extensive 
reprogramming of the Web site's applications. 
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SUMMARY OF THE INVENTION . ' 

In a computer network including oxie or more eervers and one or more 
user \mit6, at least some of which present graphical user interfaceSf a 
method for a server to communicate with at least one of the user units* 
comprising the steps of: receiving an access request from one of the user 
units, the user unit including a network browser; determining whether t he 
access request received originated from a cookies capable or cookies 
enabled network browser; and simulate and proxy cookies support at the. 
server,, oh behalf of the network browser^ at the server when it isi 
determined that the access request received originated from a non-cookies 
capable or non- cookies enabled network browser (for convenience, both of 
these kinds of browsers will be called "non* cookies capable" browsers 
hereafter) . 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a computer network in accordance with, 
one aspect of the invention; 

FIG. 2 is a block diagram of a network server in accordance with one 
aspect of the invention; 

FIG. 3 is a fl6w chart showing a process for simulating Heb cookies 
in accordance with one aspect of the invention; 

FIG. 4 is a continuation of the process of Fig. 3; and 

FIG. 5 is a sample trace of a Wei) Client HTTP Request with a cookie. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Preferred embodiments of the present invention will be described in 
detail hereinbelow with reference to the attached drawings^ ' 

FIG. 1 shows a conqputer network 10 comprising (i.e., including but 
not limited to) at least one end user station 12 and a Web server 16, both 
connected to a computer network such as the Internet 14. The end user unit 
12 can be a commercial model of a desktop microcomputer such as our IBM 
Aptiva TM personal computer or other Information processing apparatus 
suitable for communicating with a computer network. The server 16 can be 
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any of various coninercially available eerver con^wters programmatol* to 
operate in accordance with the invention. The end user station 12 ia 
connected to the server 14 via a coirputer networit such as the Intixnet 14 
or other wide area network (HAN) or local area network {UW) . 

Figure 2 is a block diagram of the network server 1« whicdi l« shown 
in FIG. I. The server 16 con«»ri8e6 conventional elements such as • cpu 18, 
working memory (e.g.'. RAM) 22. a Read-only Memory (ROM) 24. a storage 
device (e.g., a hard disk drive) 26, and a network communications swbsystw 
or interface (e.g.. a modem) 2.8. The server system 16 may also include a* 
plurality of conventional input/out (I/O) devices such aS a control console 
42 having a screen display, keyboard and mouse, and a diskette drive^ 30 for 
receiving coin>uter- readable media ju«a» as diskette 34, The server 16. may 
also include external storage 36 for additional capacity. These components 
are connected by any of several well-known buses and other connections (not 
shown) and are only representative of common components used in servers 
suitable for use on the Internet or other WMJs. The elements shown herein 
are only representative of a Web server and other -well known components 
have been oiaitted for simplicity. Ihe storage device 26 o£ the Web server 
16 con5)rise» various items of software including an operating system 38 end 
a plug. in application program 40 in accordance with the invention. The 
server also con^jrises HTTP/WEB Server software 39 comprising a plug-in 40 
m accordance with the invention, a set of Web server applications and 
content 41 and a database 43 for storing user authentication and 
preferences information. Although in this embodiment a general purpose • 
server computer is programmed to operate in accordance with the Invention 
it is also possible to implement the invention with specialised haridware. 

In operation, the user of station 12 attempts to access the Web 
server 16. As mentioned above, the Meb server 16 has a server application 
or plug-in 40 inserted in the HTTP (hypertext transfer protocol) processing 
stream 39. Various s^ervrers have similar but different facilities for 
configuring such a plug-in process.. 

Referring to FIG. 3 there is shown a flow chart illustrating, a method 
100 in accordance with the invention. The process starts when a client 
unit 12 transmits an access request to server 16. 

The plug-in 40 is the primary means for implementing the invention. 
The Web server is configured to activate a processing plug-in (step 102) 
whenever a client Web request is received to one or more areas of the 
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server. This is implemented using standard Web Server i^licatioQ 
Programming Interface (APIs) such as the Netscape Enterprise jServer APIs. 

Normally, the server 16 presents the user 12 wijth a log. in/password 
panel, creating an Identification cookie, and sends it to the user Heb . 
browser. In step i04 the Web server 1€ receivea the access request and 
invokes the pre -conf igured plug-in. The plug -in 40 determines In step 104 
whether the user's Web browser (in tJnit 12) is cookies -capable or enabled, 
by parsing the incoming * HTTP request and its headers and using a , 
pre -configured look-up- table of )cno%m Web-browser types and reported header 
fields. If the Web-browser is cookies- capable j (step 108) . the plug-in 40 
terminates and the HTTP processing proceeds as us\ial for that Web server 
16. ■ 

It the Web browser is not cookies -capable (step 112), the Web server 
plug-in 40 implementing this invention will proceed to simulate and proxy 
cookies support on behalf of the user's Web-browser. The plug-in 40 can do 
this by authenticating the user and creating an area of memory conjtaining 
the information that would be stored in the cookie residing at a user's. . 
computer. Thus the server 16, iq;>on receiving an access, would, insert the. 
client information stored in the server, into the access request just as if 
that information had been received from a cookie received from the client. 
By doing that, the plug-in 40 will allow the Web server 16 and its 
applications to. service that user without changes to server's 
implementation. The cookie prcocying plug-in performs the following 
functions: 

1. For identification/authentication of the user, the plug -in challenges 
(or prompts) the user for identification and a password using a Basic HTTP 
Authentication process, which is supported by all )cnovra browsers.. This 
causes the user's Web browser to display a dialog, box for the user . to type, 
log in and password information. These are transmitted back to the server 
(plug -in) not in the clear, but as a uu-encoded string (which is sufficient, 
security for most applications), and is all that is available in the early 
Web browsers. Uu-encoding is a scheme which converts 8 bit data such as 
programs, to a 6 bit format for transmission through 6, 7, or 8 bit 
(typically electronic mail) netvrorks. Such 6 or 7 bit networks arc 
commonly found in mainframe or UNIX operating system environments. 

2. After receiving (step 114) the user identification and password, the 
plug-in uu-decodes and authenticates the user, against the authentication 
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facilities availitble on that Web server site and its applications. ,TPhi8 
typically involves a database look-up or the invocation o£ an 
identification and password validation process. 

3. After validating and authenticating the user, the plug-in generates a 
proxy cookie structure for that user (step IIS),. This proxy cookie (or 
cookies) can be generated using one of several embodiments, includiagi 

a. A fixed format cookie with fields that are a direct function of 
the user's identification, such as a. user ID nuinb«tr. 

b. A cookie with fields that are a function of the user's 
identification and a configuration table or database lookup, a user name, 
city name, gender, or age. 

c. A cookie with fields that are a function of the user's 
identification and a collection of parameters returned from calling 
application programming interfaces and methods of Web server applications, 
such as a user ID. user name, preferences for application 1 or preferences 
for application 2. 

After generating the proxy cookie or cookies on behalf o£ the user, 
the plug- in 28 creates and maintains (step 116) a tabl« entry containing 
uu-encoded user Identification, password and the created cookie structures. 
This table will be maintained for an active user session, including 
time-out and garbage collection processing (i.e.. entries will be removed 
if not used within 15 minutes or entries will be cleared after one hour of 
first use forcing a re-authentication of the user. 

For the first and all subsequent access to that server (or other 
servers within the same domain), the user's Hcb browser will include the 
uu-encoded identification and password in the HTTP request headers. 
Referring to FIG. 4 after the initial session wherein the proxy cookie wa. 
created the server receives a subsequent access request from the same user 
(Step 118). upon receipt of subsequent access request from that user's 
unit the proxy plug -in will intercept that request and pertorm the 
following actions: 

1. Extract uu-encoded user identification and password from the HTTP 
request (step 120). 
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2. Consult its proxy-cookie table using identification and paseniord as 
the key and retrieving the proxy cookie structures (step 122). 

3. Modify the HTTP request's data to insert the proxy cookie <br 
cookies) in the. request (step 124). 

The proxy cookie plug- in then terminates (step 126) and HTTP 
processing of the request continues in the Web server site. The remaining 
of the Web server site and its applications are unaware that the user's Web 
browser lacked cookies support and can perform their tasks efficiently and 
without reprogramming . 

The iirplementation 6f this invention/ as described above* will enable 
Web server sites to use cookies for user identification and personalisation 
even for users utilizing non-coo)cies capable browsers. It involves no 
modification to the user's Web browser and assumes that bare minimum of the 
HTTP protocol that is universally implemented in all Web browsers. 
Existing Web server sites already using cookies can support these 
non-cookies capable browsers without reprogramming of applications, *^th 
adequate security, without browser discrimination and with 
high-performance, due to the server side plug-in and in-memory 
implementation of data structures. 

Each of the above functions is preferably implemented with the 
structure disclosed in FIG, 1 and FIG. 2* Specifically, the CPU 18 reads 
and executes instructions from memory 22 or storage 26. A . significant 
advantage of this invention is that it does not rely on the IP address of 
the end*user machine (browser) to maintain a user 

identification/authorization session. This is important due to the 
increasing popularity of Firewalls and Proxy/Cache servers located between 
the end-user machine and Web sites. Some alternative session 
identification iirplementations for rion-cookies enabled browsers haviT 
attempted to maintain session states using the end-user IP address in a 
table. This does not work if there are firewalls or proxy/cache servers 
between the client and the server. Therefore the solution provided. by this 
invention results in a significant advantage because it works regardless of 
firewalls or proxy/cache servers in the client-to- server path. 

Popular and high-volume Web server sites are often inqplemented as a 
cluster of independent servers, front-ended by a dispatcher. This 
invention can work in this environment by one for three ways: 
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1. Add the first authenticaticm axid cookie -siimalatic« plug- in. to th^ 
dispatching server. This has the advantage of processing the cookie/table 
creation activities only once, regardless o£ how many back-end servers and 
how many requests a client makes to that site. One potential disadvantage.,, 
is that it is usually desirable to have the dispatching server capable of 
processing 10 to 100 times more requests per second than the other servers 
in the cluster. So, adding this code to the dispatcher could bring its 
performance below tlie desired limits. 

some of the new. more sophisticated dispatching isoftware may be. able 
to guarantee that all requests from a client end up in the same back* end 
server in the cluster - this will be the optimum implementation. 

2. The first server in the cluster (behind the dispatcher) that gets a 
request form a new client and creates a simulated cookie and table entry, 
pushes this into (via HTTP, HTTPS or another API) to its peer processing 
modules in the other servers in the cluster. This has the advantage of a 
single cookie creation (with the corresponding dat^se .lookup and 
authentication) action. One potential disadvantage is that multiple 
updates in the other servers will be done and not used if the user uses the 
site for a single or very few requests. This option is a good compromise 
assuming a particular site receives several requests from a client that are 
spread over many of the servers in the cluster and it is not possible to 
add the cookie support plug-in to the dispatching server. 

3. The first server in the cluster processing a request creates the 
cookie and authentication table entry. If a sxibscqucnt requests from that 
client reaches another server, that server will use the enclosed HTTP basic 
authentication fields to inquire other servers in the cluster for the 
cookie to build its own table entry. This assumes that asking other 
servers for the entry/cookie is less expensive than accessing the PB and 
building the cookie again - that remains an option if it is less expensive 
in a particular implementation. This caption is expected to be the least 
attractive. 

High-volume sites visited by many concurrent users, may cause very 
large HTTP basic Id/password to cookie in-memory tables to be created in 
the servers. In order to address the possible performance implications of 
this, the following is used: 
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1. Use hashing algorithms to build and search the tables « 



I 
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2. Implementing aggressive timeouts to remove inactive table entries 
within short periods of time. It may be advisable to time stamp the table 
with either the time of creation an/or the time of last access. A 
background process should then scan the table and implement a clean-up 
policy that takes into account the typical user access patterns for that 
site. An example of a trace of a Web client HTTP request with cookie is 
shown in FIG. 5. 

This invention's primary application is for Web-server sites that 
want to positively identify the user (not just the client machine or 
browser with a persistent cookie) on every access session. These . 
sites/applications will always challenge the user for identification and 
possibly also for password. They then will create and serve a cookie that 
is valid for that browser session only, not saved in permanent storage 
(such as a PC hard disk f ile) « and valid for a finite amount of time 
(slightly greater than typical maximum user session time) . The cookie will 
contain user identification as well as personalisation and past history 
information to better serve the user. Sites and applications which provide 
user and prof ile -based or influenced content typically have a large 
investment in application and content delivery around cookies and 
data-mining. The system according to the invention is intended to exiable 
these sites and applications to transparently serve non-cookies enabled 
browseriB without site-wide modification. 

An alternative implementation to maintaining a table of browser HTTP 
header "signatures* to determine which browsers support or have cookies 
enabled, is as follows: 

'I. Assume, at the time of first access, that the browser does hot 
support cookies - treat all browsers the same, therefore eliminating the. 
need to maintain browser handling lists. . 

2. Process the User as described in this invention, introducing the 
simulated cookie in the stream. Simulated cookie will have at least one 
field that tells it apart from the normal cookie. 

3. Also send a normal (as opposed to simulated) cookie to the browser. 
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4. At the time of second access, if both a nprmal and simulated jCoolci* . 
are found in the HTTP request, clear the authentlcatlon/siimilated cookie 
table entry for this user, so that for all subsequent accesses, there is no 
cookie -simulation processing. 

This option should be exercised if it becotnes hard to manage and 
determine which browsers need this invention's support. There is a minor 
performance penalty, to issue two cookies on the first access, and perform 
t**o unnecessary table updates. 

While there has been illustrated and described what are presently 
considered . to be the preferred embodiments of the present invention using 
the WWW and HTML, it will be understood by those skilled in the art that 
various other modifications may be made both in WWW applications as well as 
in iii5>lementing in other client-server access protocol systems, and 
equivalents may be substituted, without departing from the true scope of. 
the invention. Additionally, many modifications may be made to adapt • 
particular situation to the teachings of the present invention without 
departing from the central inventive concept described herein. Therefore, 
it is intended that the present invention not be limited to the particular 
embodiments or protocols disclosed, but that the invention include all 
embodiments falling within the scope of the appended claims. 

m summary, there is described in a coisputer network such as the 
Internet including one or more servers and one «: more user units or 
clients wherein at least some user units do not transmit client 
identification information such as Web cookies, a method and system for 
performing the method for a server to communicate with at least one of the 
client units, comprising the steps of: receiving an access request £r«n 
one of the user units, the user unit including a network browser? 
determining whether the access request received originated from a cookies 
capable or cookies enabled network browser? and simulate and proJty cookies 
support at the server, on behalf of the network browser, at the server when 
it is determined that the access request received did not originate from a 
non-cpokies capable or non-cookies enabled netvrark browser. 



BU„d80087GBl * ' 

CXAIMS 

1. In a conputer network including one or more servers and one or more 
user units, at least some of which present graphical user interfaces, a 
method for a server to communicate with at least one o£ the user units, 
conprising the steps of: 

receiving an access request from one of the user units, the user \mit 
including a network browser; 

determining whether the access request received originated from a 
non- cookies capable or cookies enabled network browser; a[nd 

simulate and proxy cookies support, at the server, on behalC of the 
network browser, at the server when it is determined that the access 
request received originated from a non-cookies capable or non*cookies 
enabled network browser. 

2. The method of claim 1, wherein the determining step comprises parsing 
the incoming access request and its headers to determine the type of 
browser that sent the request. 

3. The method of claim 2, wherein the parsing step comprises using a 
lookup table of known browser types and reported header fields. 

4. The method of claim 1, 2 or 3 further cpii?>rising the step of 
pronpting the access requesting unit for identification aiid a password. 

5. The method of claim 4. further coii?)rising the step of receiving an 
encoded string of characters comprising the requested identification and 
passvrord . 

6. The method of claim 5, further comprising decoding the encoded string 
of characters received in claim 5 and authenticating the user requesting 
access . 

7. The method of claim 6 further comprising generating a proxy cookie 
con?>rising fields that are a direct function of the user's identification. 

8. The method of claim 4, 5, € or 7 wherein the network includes the 
Internet . 
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9. 



A machine-readable medium encoded with, a prcgoram for a serverj to • • 
communicate with at least one of the user units for performing the step, 
of « 

receiving «» .cces. request from one of the user units, the user unit 
including a network browser; 

determining whether the access request received originated from a .. 
non- cookies capable network browser; and . 

simulate and proxy cookie, support at the server, on behalf of the . 
network browser, at the server when it is determined that the acces. 
request received originated from ..non-cookie, capable or non-cookles 
enabled network brow.er. 

10 The machine-readable medium as defined In claim 9. wherein the 
determining step corprises parsing the Incoming acce.. reque.t and it. 
headers to determine the type of browser that .ent the request. 

11. The machine-readable medium as defined in claim 9 or 10. wherein the 
parsing step comprise, u.ing a lookup table of known browser types and 
reported header fields. 

12 „«chine-readable medium a. defined in cUlm 9. 10 or 11 wherein 

the medium further con^rises .instructi<». for performing the step of 
pro«^ting the access requesting unit for identification and . p.s««>rd, 

• 13 The machine-readable medium as defined in claim 11 or 12. wherein . 
comprising the step of receiving an encoded string of character. con»ri.i»g 
the. requested identification and password. . ^ ■■ 

14 The machlae-readable medium a. defined in elalm 9. 10. il. 12 or 13 
wherein further comprising decoding the encoded string of character, 
received in claim 9 and authenticating thi user requesting access. 

15 i^e machine-readable medium as defined in claim 9. wherein medium 
further comprises generating a proxy cookie comprising field, that are a 
direct function of the user's identification. 



16. A web server for providing information from a database to a user's 
system, said Web server comprising: 



B<Xy80087GBl 12 

receiving an access request from one of the u^er unite, the usfer unit 
including a network browser; 

determining whether the access request received originated from a 
cookies capable or cookies enabled network browser; and 

simulate and proxy cookies support at the server, on behalf of the 
network browser, at the server when it is determined that the access 
request received originated from a non-cookies capable or non-cookies 
enabled network browser. 

17. The web server as defined in claim 16., wherein the means for 
determining coiqprises means for parsing the incoming access request and its 
headers to determine the type of browser that sent the request. • 

18. The Web server as defined in claim 16 or 17, wherein the means for 
parsing comprises a lookup table of known browser types and reported header 
fields.. 

19. The Web server of claim 16, 17 or 18 further coii5>rising the means for 
proii?>ting the access requesting unit for identification and a password, 

20. The web server of claim 16, 17, 18 or 19 further comprising means for 
receiving the encoded string of characters comprising the requested 
identification and password. 

21. The Web server of further con?)rising means for decoding received in 
claim 15 and authenticating the user requesting access. 

22. A proxy Web cookie article of manufacture conqprising: 

instructions for intercepting an HTTP access request, the access 
request comprising user identification and password. data; 

instructions for consulting a proxy cookie table using the 
identification and password as a key and for retrieving proxy cookie 
structures therefrom; and 

instructions for modifying the HTTP access requests data to insert at 
least one proxy cookie structure. 
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